fix(domain_fronter): large download resilience, stream timeout decoupling, and compact log timestamps#1346
Open
CaptainMirage wants to merge 3 commits into
Open
Conversation
Inside the MITM TLS session, detect Connection: Upgrade + Upgrade: websocket before hitting the Apps Script relay. Establish a direct TLS connection to the real server (via upstream_socks5 if configured), relay the upgrade handshake, then splice both directions with copy_bidirectional. Apps Script cannot hold persistent connections so the bypass is the only viable path for wss://. Split request_timeout_secs (header/connect, 30s) from a new stream_timeout_secs (per-chunk body idle, default 300s) so large range downloads through Apps Script are not killed mid-transfer by the batch_timeout firing during the body drain phase.
Handle idempotent exit-node timeouts by falling back to direct Apps Script, route Range: bytes=N- requests through parallel resume streaming, and send TLS close_notify on shutdown so wget/curl can resume from the correct offset.
Adds src/logging.rs with CompactUtcTime (FormatTime impl, time crate). Replaces the default ISO 8601 timestamp with [2026-05-22]-[12:56:28.9]. ANSI-gated colouring on terminals: orange date digits, light blue time digits, darker shades on internal punctuation, gray brackets/separator, green separator dash. Plain text fallback for the UI log panel and Android Logcat. Wired into all three subscriber setups (main, UI, JNI). Also fixes a compile error in the UI binary: stream_timeout_secs was added to Config in b3c51e0 but never plumbed through FormState. Added to the struct, both init paths (load-from-config and fresh-default), to_config() output, and ConfigWire so Save doesn't drop a non-default value.
Contributor
Author
|
i assume you are quite busy aleph but if you dont mind could you respond a tad bit faster? i keep digging myself into a hole by editing files i have already made a PR for and i have to wait for one to be reviewed before i can push the other one, pardon me, i just want to move a tad bit quicker many thanks my good sir |
This was referenced May 24, 2026
Contributor
Author
|
aleph could you please turn on discussions tab on this repo so people will stop using the issues tab for discussions basically? thats what that tab is for afterall, i wanna use the issues for making issues to track properly and get reports on but its filled with people constantly asking the same things, we need a frequently asked Q&A in it too, would be lovely if you did that and or got someone else to be a maintainer too, thank you |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Large download resilience — range requests (
Range: bytes=N-) arenow routed through a parallel resume streaming path. Idempotent
exit-node timeouts fall back to direct Apps Script instead of aborting.
TLS
close_notifyis sent on shutdown so wget/curl can resume fromthe correct offset.
Stream timeout decoupling — splits
request_timeout_secs(header/connect phase, 30 s) from a new
stream_timeout_secs(per-chunk body idle, default 300 s) so large transfers through Apps
Script are no longer killed mid-body by the batch timeout firing
during the drain phase.
Compact log timestamps — replaces the noisy ISO 8601 default
(
2026-05-22T12:56:28.992990Z) with[2026-05-22]-[12:56:28.9].Terminal output gets ANSI colouring (orange date, light blue time,
gray structure); UI log panel and Android Logcat stay plain text.
Here are the log timestamp colours; they may vary slightly depending on the terminal, since they use ANSI colouring :
i also looked into fixing WebSocket support in Apps Script proxy mode, but in practice i dropped it
the main issue is that Apps Script web app requests don’t stay alive long enough for a stable long-lived WebSocket path, in my testing, they die around the ~6 minute mark, which matches the general Apps Script execution/runtime limits. I even built and tested a local ws tunnel layer for this, but the connection still could not survive past that limit reliably
that would already make the Apps Script WebSocket path fragile, but the bigger problem is what happens after the upstream socket dies. Some services (Discord especially) can behave badly here depending on how the client/library handles the close, so just letting the tunnel die and hoping reconnect works is not good enough. To make it usable, it would need a more dynamic reconnect/rebind system on top
at that point it becomes a lot of extra complexity for something that still has a built-in timeout ceiling every few minutes, while the Google Cloud path already solves the problem properly, so i dropped it
for lighter WebSocket use cases, like short-lived notifications or some live-feed scenarios, this limitation may be less painful. But for something like Discord, where long-lived stable gateway connections matter, it is too annoying to justify